Performance optimization for data visualization

ABSTRACT

Performance optimization for reduced and bounded memory cost for data visualization is provided. Performance optimization comprises: data culling, geometry culling, and cloning of a visualization to a background thread for layout. The performance optimization leverages a data visualization architecture for building of a data visualization via a one-directional chain of separate stages, wherein data at each stage may be culled or privatized to reduce the amount of data, or simplify the nature of the data, to be processed in subsequent stages, thus improving overall system performance and user experience.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional PatentApplication No. 62/063,741, titled “Data Visualization” filed Oct. 14,2014.

BACKGROUND

Data visualization is a process for graphically representing data in avisualization, for example, a chart, an infographic, a map, a gauge,etc. Visualizations of large data sets require signification systemresources, including processor time and memory, to prepare or store thevisualization, which can cause the system to lock up or slow down. It iswith respect to these and other considerations that examples will bemade.

SUMMARY

This summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription section. This summary is not intended to identify allfeatures of the claimed subject matter, nor is it intended to limit thescope of the claimed subject matter.

Aspects of the present disclosure provide performance optimization byculling data from a data visualization to reduce memory requirements.According to one aspect, data is culled during layout time tointelligently skip data that does not materially impact the presentationof the visualization; preserving the presentation while reducingcomplexity. According to another aspect, geometry produced during layoutis culled such that the geometry vectors are reduced orsimplified/trimmed to reduce post-layout processing (e.g., rendering).According to another aspect, each series layout uses private optimizeddata structures to store geometry in abstract form for reduced memoryusage. Aspects of the present disclosure also provide for deferring thecost of layout to a background thread by cloning a visualization andperforming layout on the background thread, then transferring thecomputed layout to the foreground thread in near constant time.

Examples may be implemented as a computer process, a computing system,or as an article of manufacture such as a computer program product orcomputer readable media. The computer program product may be a computerstorage media readable by a computer system and encoding a computerprogram of instructions for executing a computer process.

The details of one or more aspects are set forth in the accompanyingdrawings and description below. Other features and advantages will beapparent from a reading of the following detailed description and areview of the associated drawings. It is to be understood that thefollowing detailed description is explanatory only and is notrestrictive of the present disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of this disclosure, illustrate various aspects of the presentdisclosure. In the drawings:

FIG. 1 illustrates a pipelined architecture in which data flows in asingle direction;

FIG. 2 illustrates a block diagram of a system for optimizing theperformance of creating and laying out a visualization;

FIG. 3 is a flow chart showing general stages involved in a method forproviding data visualization platform performance optimization

FIG. 4 is a block diagram illustrating example physical components of acomputing device;

FIGS. 5A and 5B are block diagrams of a mobile computing device; and

FIG. 6 is a block diagram of a distributed computing system.

DETAILED DESCRIPTION

The following detailed description refers to the accompanying drawings.Wherever possible, the same reference numbers are used in the drawingsand the following description to refer to the same or similar elements.While aspects of the disclosure may be described, modifications,adaptations, and other implementations are possible. For example,substitutions, additions, or modifications may be made to the elementsillustrated in the drawings, and the methods described herein may bemodified by substituting, reordering, or adding stages to the disclosedmethods. Accordingly, the following detailed description does not limitthe present disclosure, but instead, the proper scope of the disclosureis defined by the appended claims. Examples may take the form of ahardware implementation, or an entirely software implementation, or animplementation combining software and hardware aspects. The followingdetailed description is, therefore, not to be taken in a limiting sense.

As is commonly known in the art, memory is often a bottleneck forapplication performance. Aspects allow for application performance to beoptimized by bounding the amount of memory used and by storing data in asingle, contiguous allocation. As described below, when geometry iscomputed by a layout engine, it may be cached within a bounded seriesobject. Aspects provide for data culling and the privatization, on aper-layout basis, for storing abstracting geometry to optimizeperformance.

Examples of the present disclosure are directed to providing performanceoptimization within a data visualization platform architecture viaculling data from a data visualization. According to an aspect, thearchitecture enables building of a data visualization (e.g., a chart, aninfographic, a map, a gauge, etc.) via a one-directional chain ofseparate stages, each stage having a simple input interface and outputinterface.

FIG. 1 illustrates a pipelined architecture 100 in which data flows in asingle direction. As illustrated in FIG. 1, data flows from raw data105, to abstract geometry 115, to series object 125, to visualization135. Data can be privatized or culled at each stage in the pipeline,which reduces the memory used for laying out and creating avisualization 135. Accordingly, visualization generation is performedmore efficiently.

Raw data 105 comprises the collection of data points to be plotted in avisualization 135. Raw data 105 in various aspects is organized by rows,vectors, arrays, tables, matrices, etc. In on example, raw data 105 istaken from a group of cells in the EXCEL® spreadsheet software, offeredby MICROSOFT CORPORATION of Redmond, Wash. Visualizations 135 include,for example, charts, infographics, maps, gauges, etc., which are used tographically display the raw data 105.

Abstract geometry 115 comprises a limited set of primitives (e.g.,lines, Beziers curves, Bezier surfaces, etc.) which can be passeddirectly to an appropriate rendering Application Programming Interface(API) or to an additional module or engine for further processing. Fromthese primitives, any geometry can be approximated.

According to aspects, the abstract geometries 115 are stored as a seriesobject 125 in a compact form that is tailored to each type of layout. Inseveral aspects, the abstract geometries 115 are assembled into a seriesobject 125 that is stored in a single allocation as a continuous blockin memory, which improves the speed of retrieval. According to aspects,a series object 125 is a form of privatized storage, which is operableto provide all the abstract geometries 115 comprising it without beinginterrogated for individual abstract geometries 115; the entire seriesobject 125 is provided in one synchronous operation to produce thevisualization 135. According to aspects, the amount of abstract geometry115 cached within a series object 125 is bounded by the display size ofthe visualization 135 and is computed to have a fixed cost in memory.When the size of series objects 125 is bounded, some aspects usemultiple series objects 125 to create portions of the visualization 135.One example of a series objects 125 is a circle comprised of abstractgeometry 115 (e.g., four cubic Beziers, each comprising a quadrant ofthe circle), which may represent the raw data 105 in the visualization135 as a function of the circle's radius.

Abstract geometries 115 are stored in various forms according to variousaspects. According to one aspect, abstract geometries 115 are stored asa master and instances compact form (e.g., lists of rectangles, circles,diamonds, lines, pie slices, etc.). A master and instances compact formenables a visualization type that uses geometry with repeating forms(e.g., a scatter series where each data point is a diamond shape) toimprove performance by compacting the volume of series objects 125 to beprovided. Aspects enable the visualization 135 to use geometry in themaster/instances form, whereby the master geometry of a series object125 (e.g., a diamond) is described once in full detail and the instancesreference the master geometry and are described as a single point (e.g.,the center of the diamond) about which the master geometry isconstructed in the visualization 135. According to another aspect,abstract geometries 115 can be stored as path geometry (e.g., areacharts, surface charts, radar charts, trend lines, etc.). According toanother aspect, abstract geometries 115 can be stored as a formula. Forexample, in a business chart plotting supply and demand curves,functions describing the curves are stored. Accordingly, the abstractgeometry 115 can be synthesized during rendering. For example, in casesof simple layout (e.g., line charts, column charts, etc.) that arecomputationally inexpensive and where the data is local, abstractgeometry 115 may be synthesized directly from the raw data 105.

FIG. 2 illustrates a block diagram of a system 200 for optimizing theperformance of creating and laying out a visualization 135. In thesystem 200, data is passed to a layout engine 210 from client 240 duringthe layout phase of creating a visualization 135, processed, andabstract geometry 115 is passed back to the client 240 to provide thevisualization 135. The data received from the client 240 includes rawdata 105 and a surface description 235, which provides context on theclient 240 and a coordinate space in which the raw data 105 will bevisualized. According to one aspect, data is passed to a series layoutmodule 250 to create abstract geometry 115 according to the surfacedescription 235 to graphically represent the raw data 105 in avisualization 135, which in turn is passed back to the layout engine 210to cull the abstract geometry 115 before it is transmitted to the client240. The system 200 is operable to privatize or cull data or geometry atany point.

During the layout phase of creating a visualization 135, raw data 105received from the client 240 is converted into abstract geometry 115.According to an aspect, when the layout engine 210 is constructing alayout, the data culler 220 performs a layout-specific culling of theraw data 105 using custom culling logic. Raw data 105 that, if removed,does not materially impact the visualization 135, as determined by thecustom culling logic, is culled; it is ignored or skipped when geometryis calculated. According to an aspect, data that is culled is retainedby the layout engine 210 or the client 240, but is not transmitted tothe series layout module 250 or used in subsequent operations. The dataculler 220 enables the layout engine 210 to construct a visualization135 that will still convey the same interpretation of the raw data 105,but using less data.

According to aspects, raw data 105 is culled when its graphicalrepresentation in the visualization 135 is materially affected by thepresentation of other raw data 105. For example, in a visualization 135of a column series, where data series comprising the raw data 105 arevisualized as vertical columns, data series are culled from the raw data105 when the vertical columns of other data series would overlap them inthe visualization 135. In another example, in a visualization 135 of abubble series, raw data 105 (represented as circles) are culled fromareas of high density within the bubble chart.

According to aspects, each visualization type comprises custom cullinglogic appropriate for its layout. In these aspects, a particular cullinglogic is chosen based on the visualization type (e.g., column, scatter,pie, etc.) that selectively skips/ignores raw data 105 that wouldproduce abstract geometry 115 or series objects 125 that materiallyaffect the display of other abstract geometry 115 or series objects 125.According to aspects, the raw data 105 is not deleted in a cull; it ismerely ignored for purposes of creating a visualization 135. In variousaspects, raw data 105 that is not culled is converted to the appropriateprimitives that can be used to synthesize geometry for downstreamprocesses in the pipelined architecture 100 (e.g., rendered orinteracted with via the visualization 135). By culling the raw data 105,processes occurring later in the pipelined architecture 100 are providedwith a reduced amount of data to manipulate while providing anequivalent interpretation of the data.

According to another aspect, as the abstract geometry 115 is producedduring the layout phase, a geometry culler 230 culls abstract geometry115 further to reduce rendering and rasterization costs of abstractgeometry 115 and series objects 125 that are too complex for the currentoutput resolution of the client 240 (or the device on which the client240 is executed). In various aspects, the geometry culler 230 executesgeometry culling logic to drop abstract geometry 115 or convert it to asimpler form when the visualized abstract geometry 115 will fall below asize threshold within the visualization 135. According to an aspect, thegeometry culler 230 is operable to drop abstract geometry 115 when theculling will not materially impact the displayed visualization 135. Forexample, the geometry culler 230 drops the abstract geometry 115 forempty series objects 125 and line segments that will be rendered in thevisualization 135 with zero-length, trims/converts rectangles with zeroheight/width and short Bezier curves (e.g., less than 4 pixels) intolines, combines collinear segments, etc. According to aspects, thegeometry culler 230 reduces the number of primitives needed to display aset of abstract geometry 115 without materially affecting thevisualization 135 according to the surface description 235. Bypresenting abstract geometry 115 comprised of fewer or simplerprimitives (e.g., lines instead of Beziers), geometry culling reducesthe amount of processing required by subsequent stages in the pipelinedarchitecture 100.

Aspects provide for a surface description 235 (e.g., visualization type,visualization size, client resolution/dpi, etc.) to be generated for thevisualization 135 to provide client context on which the cullingthresholds are based. For example, a client 240 with a displayresolution of 1920×1080 pixels has greater resolution than a client 240with a display resolution of 800×600 pixels, which is not able todisplay the same visualization 135 with as great of detail as the client240 with the larger resolution. Accordingly, a geometry for a rectangledisplayed on the client 240 with the larger resolution may be culled tobe displayed as a line (or not displayed at all) on the client 240 withthe smaller resolution. The surface description 235 is used by the dataculler 220 to determine when abstract geometries 115 will materiallyimpact one another (and thereby cull the associated raw data 105) and bythe geometry culler 230 to determine when an abstract geometry 115 canbe dropped or simplified/trimmed without materially affecting thedisplay of the visualization 135.

According to aspects, the entire data set is processed during the layoutphase in order to produce the correct and reduced set of abstractgeometries 115, can take a long time and can introduce brief hangs andmoments of unresponsiveness in the User Interface (UI) of a client 240.For example, to create a visualization 135 based on a million rows ofraw data 105, a million rows of raw data 105 are “walked through” (i.e.,processed row-by-row) to perform the data culling process and theresulting abstract geometries 115 are similarly processed to perform thegeometry culling. Aspects provide for deferring the cost of the layoutphase to a background thread to improve responsiveness by allowing theclient 240 to clone the visualization 135 and push the layout phase to abackground thread. As is known in the art, cloning can be achieved innear-constant time (e.g., less than 0.5 ms). The background layoutprocess allows the client 240 to still be responsive to user input whilethe layout of the visualization 135 is calculated in the background.Aspects allow for the foreground visualization 135 to remain blank,display a previous layout, display a progress bar (or similar indicationof the ongoing layout process) for the background thread or combinationsthereof. Aspects also allow for the background thread to be aborted bythe client 240, such as, for example, when a user manually aborts orwhen a second request is made. According to aspects, once the backgroundlayout phase is complete, the computed layout can be transferred back toa foreground thread at near constant time via an API that involves apointer swap to replace or update the visualization 135 in theforeground.

FIG. 3 is a flow chart showing general stages involved in a method 300for providing data visualization platform performance optimization.Method 300 begins at START 301 and proceeds to OPERATION 310, where thedata to be used in a visualization 135 is received. According toaspects, the received data includes raw data 105 and the surfacedescription 235 for the visualization 135.

Method 300 then proceeds to OPERATION 320, where the layout is pushed toa background thread. The layout is pushed to a background thread toprevent hangs or moments of unresponsiveness that may be introduced inthe UI of a client 240 during processing. Method 300 then proceeds toDECISION OPERATION 330.

At DECISION OPERATION 330, a determination is made as to whether to cullthe raw data 105 based on the coordinate system requirements (e.g.,Cartesian, value/value (e.g. scatter chart); Cartesian, category/value(e.g., column chart); radial, category/value (e.g., pie chart, radarchart); etc.) and display dimensions for the visualization 135 retrievedvia the surface description 235. From the surface description 235 and ananalysis of the raw data 105, a determination can be made whether thegeometry for two data series or data points will overlap on the displaysurface. For example, when creating a five-inch-wide column chart on amonitor that has a hundred pixels per inch (i.e., a chart of 500pixels), a determination can be made that the visualization can draw atmost 500 one-pixel-wide columns in the example chart. Accordingly,displaying more than 500 data series of the raw data 105 would cause theassociated abstract geometry 115 to materially affect one another (e.g.,overlap), and it can be determined that the raw data 105 is to beculled.

When the determination is made to cull the raw data 105, method 300proceeds to OPERATION 335, where, according to aspects, the raw data 105is culled according to layout-specific, custom culling logic (e.g., fora scatter series, overlapping markers are dropped) and method 300 thenproceeds to OPERATION 340. According to various aspects, raw data 105may be culled according to several culling schemes, which may beuser-defined or set by the system based on the visualization type,according to various aspects, including: by sequential truncation (e.g.,ignoring data series after a threshold is reached), interleavedtruncation (e.g., every other data series is culled), merging (e.g.,combining small data series in appropriate visualization, such as a piechart, into a “miscellaneous” data series), outlier culling, etc.

When the determination is made to not cull the raw data 105, or whenculling is complete, method 300 proceeds to OPERATION 340.

Abstract geometries 115 are calculated and generated at OPERATION 340 torepresent the raw data 105 in the visualization 135. According to anaspect, abstract geometries 115 are calculated and generatedindividually for each data series comprising the raw data 105. Accordingto an aspect, abstract geometries are comprised of primitives (e.g.,lines, Bezier curves, Bezier surfaces, etc.).

Method 300 then proceeds to DECISION OPERATION 350, where is itdetermined whether to cull the abstract geometry 115 based on thedisplay characteristics of the client 240 and the visualization 135retrieved via the surface description 235. Continuing the example givenin relation to DECISION OPERATION 330, if 500 columns were to berendered as rectangles having a width of one pixel, the decision to cull(via trimming) their geometry from rectangles to lines can be madewithout materially affecting the visualization 135; the visualization135 will look substantially the same to a user.

When the determination is made to cull the abstract geometry 115, method300 proceeds to OPERATION 355, where the abstract geometry 115 is culledaccording to geometry culling logic. In aspects, culling the primitivescomprising the abstract geometry 115 includes, but is not limited to:setting a master and instance format, so that a geometry is only passedonce to the client 240; trimming the primitives of abstract geometries(e.g., a rectangle of width/height of one pixel can be represented as aline, a short curve can be represented as a line, etc.), to reduce theamount of processing needed by the client 240; dropping negligiblegeometry, such as the abstract geometry 115 corresponding to data seriesthat are empty, zero-value, or too small to be accurately displayed inthe visualization 135 (e.g., slices of a pie chart that would be toothin to be accurately displayed as a line on the chart) to reducerendering time needed by the client 240; combining the primitives ofcollinear segments to group processes for the client; etc. According toaspects, because abstract geometry 115 is generated individually foreach data series, it is also processed and culled individually, whichallows method 300 to begin geometry culling before all abstract geometry115 has been generated at OPERATION 340.

When the determination is made to not cull the abstract geometry, orwhen culling is complete, method 300 proceeds to OPERATION 360, wherethe abstract geometries 115 are privately stored on a per-series layoutbasis, such as, for example, via a series object 125. In variousaspects, series objects 125 are stored in a single allocation as acontiguous block in memory, which improves the speed of retrieval. Inaspects, a series object 125 is bounded by the display constraints ofthe visualization 135, as indicated by the surface description 235, andis computed to have a fixed cost in memory, such that it can beretrieved from memory in near-constant time (e.g., less than 0.5 ms). Insome aspects, each series object 125 corresponds to a data series (or,in other aspects, a combined data series) and can be storedindividually, which allows method 300 to begin storing before allabstract geometry 115 has been culled according to OPERATION 355.According to an aspect, several series objects 125 are stored inadjacent continuous blocks in memory, which further improves the speedof retrieval in OPERATION 380. Method 300 then proceeds to OPERATION370.

At OPERATION 370, the computed layout is transferred back to aforeground thread from the background thread.

Method 300 then proceeds to OPERATION 380, where the abstract geometry115 is provided to the client 240. According to aspects, the abstractgeometry 115 is streamed as series objects 125 to the client 240. Afterthe client 240 receives the abstract geometry 115, the visualization 135can be provided, and method 300 concludes at END 399.

FIGS. 4-6 and the associated descriptions provide a discussion of avariety of operating environments in which examples of the disclosuremay be practiced. However, the devices and systems illustrated anddiscussed with respect to FIGS. 4-6 are for purposes of example andillustration and are not limiting of a vast number of computing deviceconfigurations that may be used for practicing aspects of thedisclosure, described herein.

FIG. 4 is a block diagram illustrating physical components (i.e.,hardware) of a computing device 400 with which examples of the presentdisclosure may be practiced. The computing device components describedbelow may be suitable for the client device described above. In a basicconfiguration, the computing device 400 may include at least oneprocessing unit 402 and a system memory 404. Depending on theconfiguration and type of computing device, the system memory 404 maycomprise, but is not limited to, volatile storage (e.g., random accessmemory), non-volatile storage (e.g., read-only memory), flash memory, orany combination of such memories. The system memory 404 may include anoperating system 405 and one or more programming modules 406 suitablefor running software applications 450, such as layout engine 210.According to an aspect, the system memory 404 may include the client240. The operating system 405, for example, may be suitable forcontrolling the operation of the computing device 400. Furthermore,aspects of the invention may be practiced in conjunction with a graphicslibrary, other operating systems, or any other application program andis not limited to any particular application or system. This basicconfiguration is illustrated in FIG. 4 by those components within adashed line 408. The computing device 400 may have additional featuresor functionality. For example, the computing device 400 may also includeadditional data storage devices (removable or non-removable) such as,for example, magnetic disks, optical disks, or tape. Such additionalstorage is illustrated in FIG. 4 by a removable storage device 409 and anon-removable storage device 410.

As stated above, a number of program modules and data files may bestored in the system memory 404. While executing on the processing unit402, the program modules 406 (e.g., client 240, layout engine 210) mayperform processes including, but not limited to, one or more of thestages of the method 300 illustrated in FIG. 3. Other program modulesthat may be used in accordance with examples of the present disclosureand may include other applications 450 such as, for example, electronicmail and contacts applications, word processing applications,spreadsheet applications, database applications, slide presentationapplications, drawing or computer-aided application programs, etc.

Furthermore, examples of the disclosure may be practiced in anelectrical circuit comprising discrete electronic elements, packaged orintegrated electronic chips containing logic gates, a circuit using amicroprocessor, or on a single chip containing electronic elements ormicroprocessors. For example, examples of the disclosure may bepracticed via a system-on-a-chip (SOC) where each or many of thecomponents illustrated in FIG. 4 may be integrated onto a singleintegrated circuit. Such an SOC device may include one or moreprocessing units, graphics units, communications units, systemvirtualization units and various application functionality all of whichare integrated (or “burned”) onto the chip substrate as a singleintegrated circuit. When operating via an SOC, the functionality,described herein, may be operated via application-specific logicintegrated with other components of the computing device 400 on thesingle integrated circuit (chip). Examples of the present disclosure mayalso be practiced using other technologies capable of performing logicaloperations such as, for example, AND, OR, and NOT, including but notlimited to mechanical, optical, fluidic, and quantum technologies. Inaddition, aspects of the disclosure may be practiced within a generalpurpose computer or in any other circuits or systems.

The computing device 400 may also have one or more input device(s) 412such as a keyboard, a mouse, a pen, a sound input device, a touch inputdevice, etc. The output device(s) 414 such as a display, speakers, aprinter, etc. may also be included. The aforementioned devices areexamples and others may be used. The computing device 400 may includeone or more communication connections 416 allowing communications withother computing devices 418. Examples of suitable communicationconnections 416 include, but are not limited to, RF transmitter,receiver, or transceiver circuitry; universal serial bus (USB),parallel, or serial ports.

The term computer readable media as used herein may include computerstorage media. Computer storage media may include volatile andnonvolatile, removable and non-removable media implemented in any methodor technology for storage of information, such as computer readableinstructions, data structures, or program modules. The system memory404, the removable storage device 409, and the non-removable storagedevice 410 are all computer storage media examples (i.e., memorystorage.) Computer storage media may include RAM, ROM, electricallyerasable programmable read-only memory (EEPROM), flash memory or othermemory technology, CD-ROM, digital versatile disks (DVD) or otheroptical storage, magnetic cassettes, magnetic tape, magnetic diskstorage or other magnetic storage devices, or any other article ofmanufacture which can be used to store information and which can beaccessed by the computing device 400. Any such computer storage mediamay be part of the computing device 400. Computer storage media does notinclude a carrier wave or other propagated data signal.

Communication media may be embodied by computer readable instructions,data structures, program modules, or other data in a modulated datasignal, such as a carrier wave or other transport mechanism, andincludes any information delivery media. The term “modulated datasignal” may describe a signal that has one or more characteristics setor changed in such a manner as to encode information in the signal. Byway of example, and not limitation, communication media may includewired media such as a wired network or direct-wired connection, andwireless media such as acoustic, radio frequency (RF), infrared, andother wireless media.

FIGS. 5A and 5B illustrate a mobile computing device 500, for example, amobile telephone, a smart phone, a tablet personal computer, a laptopcomputer, and the like, with which aspects of the disclosure may bepracticed. With reference to FIG. 5A, an example of a mobile computingdevice 500 for implementing the aspects is illustrated. In a basicconfiguration, the mobile computing device 500 is a handheld computerhaving both input elements and output elements. The mobile computingdevice 500 typically includes a display 505 and one or more inputbuttons 510 that allow the user to enter information into the mobilecomputing device 500. The display 505 of the mobile computing device 500may also function as an input device (e.g., a touch screen display). Ifincluded, an optional side input element 515 allows further user input.The side input element 515 may be a rotary switch, a button, or anyother type of manual input element. In alternative examples, mobilecomputing device 500 may incorporate more or less input elements. Forexample, the display 505 may not be a touch screen in some examples. Inalternative examples, the mobile computing device 500 is a portablephone system, such as a cellular phone. The mobile computing device 500may also include an optional keypad 535. Optional keypad 535 may be aphysical keypad or a “soft” keypad generated on the touch screendisplay. In various aspects, the output elements include the display 505for showing a graphical user interface (GUI), a visual indicator 520(e.g., a light emitting diode), or an audio transducer 525 (e.g., aspeaker). In some examples, the mobile computing device 500 incorporatesa vibration transducer for providing the user with tactile feedback. Inyet another example, the mobile computing device 500 incorporatesperipheral device ports 540, such as an audio input (e.g., a microphonejack), an audio output (e.g., a headphone jack), and a video output(e.g., a HDMI port) for sending signals to or receiving signals from anexternal device.

FIG. 5B is a block diagram illustrating the architecture of one exampleof a mobile computing device. That is, the mobile computing device 500can incorporate a system (i.e., an architecture) 502 to implement someexamples. In one example, the system 502 is implemented as a “smartphone” capable of running one or more applications (e.g., browser,e-mail, calendaring, contact managers, messaging clients, games, andmedia clients/players). In some examples, the system 502 is integratedas a computing device, such as an integrated personal digital assistant(PDA) and wireless phone.

One or more application programs 450, for example, client 240, may beloaded into the memory 562 and run on or in association with theoperating system 564. Examples of the applications 450 include phonedialer programs, e-mail programs, personal information management (PIM)programs, word processing programs, spreadsheet programs, Internetbrowser programs, messaging programs, and so forth. According to anaspect, the layout engine 210 may be loaded into memory 562. The system502 also includes a non-volatile storage area 568 within the memory 562.The non-volatile storage area 568 may be used to store persistentinformation that should not be lost if the system 502 is powered down.The applications 450 may use and store information in the non-volatilestorage area 568, such as e-mail or other messages used by an e-mailapplication, and the like. A synchronization application (not shown)also resides on the system 502 and is programmed to interact with acorresponding synchronization application resident on a host computer tokeep the information stored in the non-volatile storage area 568synchronized with corresponding information stored at the host computer.As should be appreciated, other applications may be loaded into thememory 562 and run on the mobile computing device 500.

The system 502 has a power supply 570, which may be implemented as oneor more batteries. The power supply 570 might further include anexternal power source, such as an AC adapter or a powered docking cradlethat supplements or recharges the batteries.

The system 502 may also include a radio 572 that performs the functionof transmitting and receiving radio frequency communications. The radio572 facilitates wireless connectivity between the system 502 and the“outside world,” via a communications carrier or service provider.Transmissions to and from the radio 572 are conducted under control ofthe operating system 564. In other words, communications received by theradio 572 may be disseminated to the application programs 450 via theoperating system 564, and vice versa.

The visual indicator 520 may be used to provide visual notifications oran audio interface 574 may be used for producing audible notificationsvia the audio transducer 525. In the illustrated example, the visualindicator 520 is a light emitting diode (LED) and the audio transducer525 is a speaker. These devices may be directly coupled to the powersupply 570 so that when activated, they remain on for a durationdictated by the notification mechanism even though the processor 560 andother components might shut down for conserving battery power. The LEDmay be programmed to remain on indefinitely until the user takes actionto indicate the powered-on status of the device. The audio interface 574is used to provide audible signals to and receive audible signals fromthe user. For example, in addition to being coupled to the audiotransducer 525, the audio interface 574 may also be coupled to amicrophone to receive audible input, such as to facilitate a telephoneconversation. The system 502 may further include a video interface 576that enables an operation of an on-board camera 530 to record stillimages, video stream, and the like.

A mobile computing device 500 implementing the system 502 may haveadditional features or functionality. For example, the mobile computingdevice 500 may also include additional data storage devices (removableor non-removable) such as, magnetic disks, optical disks, or tape. Suchadditional storage is illustrated in FIG. 5B by the non-volatile storagearea 568.

Data/information generated or captured by the mobile computing device500 and stored via the system 502 may be stored locally on the mobilecomputing device 500, as described above, or the data may be stored onany number of storage media that may be accessed by the device via theradio 572 or via a wired connection between the mobile computing device500 and a separate computing device associated with the mobile computingdevice 500, for example, a server computer in a distributed computingnetwork, such as the Internet. As should be appreciated suchdata/information may be accessed via the mobile computing device 500 viathe radio 572 or via a distributed computing network. Similarly, suchdata/information may be readily transferred between computing devicesfor storage and use according to well-known data/information transferand storage means, including electronic mail and collaborativedata/information sharing systems.

FIG. 6 illustrates one example of the architecture of a system forproviding data visualization as described above. Content developed,interacted with, or edited in association with the client 240 or thelayout engine 210 may be stored in different communication channels orother storage types. For example, various documents may be stored usinga directory service 622, a web portal 624, a mailbox service 626, aninstant messaging store 628, or a social networking site 630. The client240 or layout engine 210 may use any of these types of systems or thelike for providing data visualization, as described herein. A server 615may provide the client 240 or layout engine 210 to clients 605A-C. Asone example, the server 615 may be a web server providing the client 240or layout engine 210 over the web. The server 615 may provide the client240 or layout engine 210 over the web to clients 605 through a network610. By way of example, the client computing device may be implementedand embodied in a personal computer 605A, a tablet computing device 605Bor a mobile computing device 605C (e.g., a smart phone), or othercomputing device. Any of these examples of the client computing devicemay obtain content from the store 616.

Aspects of the present disclosure, for example, are described above withreference to block diagrams or operational illustrations of methods,systems, and computer program products according to aspects of thedisclosure. The functions/acts noted in the blocks may occur out of theorder as shown in any flowchart. For example, two blocks shown insuccession may in fact be executed substantially concurrently or theblocks may sometimes be executed in the reverse order, depending uponthe functionality/acts involved.

The description and illustration of one or more examples provided inthis application are not intended to limit or restrict the scope of thepresent disclosure in any way. The aspects, examples, and detailsprovided in this application are considered sufficient to conveypossession and enable others to make and use the best mode of presentdisclosure. The present disclosure should not be construed as beinglimited to any aspect, example, or detail provided in this application.Regardless of whether shown and described in combination or separately,the various features (both structural and methodological) are intendedto be selectively included or omitted to produce an example with aparticular set of features. Having been provided with the descriptionand illustration of the present application, one skilled in the art mayenvision variations, modifications, and alternate examples fallingwithin the spirit of the broader aspects of the general inventiveconcept embodied in this application that do not depart from the broaderscope of the present disclosure.

We claim:
 1. A method for providing performance optimization for datavisualization, comprising: receiving data including raw data, comprisedof a plurality of data points to be displayed via graphicalrepresentations in a visualization, and a surface description for thevisualization; processing the raw data to determine whether to cull afirst data point from the plurality of data points, wherein the firstdata point is culled when the surface description indicates that agraphical representation of the first data point will be materiallyaffected by a graphical representation of a second data point;generating abstract geometry comprised of primitives to graphicallyrepresent unculled data points in the data visualization; processing theabstract geometry to determine whether to cull abstract geometry,wherein culling the abstract geometry reduces the primitives comprisingthe abstract geometry without materially affecting the visualization tothereby improve rendering efficiency; and storing the abstract geometryas a series object within a contiguous block of memory, the seriesobject configured for near-constant retrieval for the visualization. 2.The method of claim 1, wherein the steps of the method are performed ina background thread, such that a client executing the method does notexperience periods of unresponsiveness in a user interface due toexecuting the method.
 3. The method of claim 1, wherein the surfacedescription further indicates that the first data point is to be culledwhen abstract geometry representing the data points comprising theplurality of data points contains exceeds an a display area of thevisualization.
 4. The method of claim 1, wherein the determination tocull the first data point is based on a custom culling logiccorresponding to a type of the visualization.
 5. The method of claim 1,wherein reducing the primitives comprising the abstract geometryincludes at least one of: combining collinear primitives; and droppingnegligible geometry from the visualization, such that the droppednegligible geometry is not stored.
 6. The method of claim 1, whereinreducing the primitives comprising the abstract geometry furthercomprises: a describing a master geometry, operable to be stored andretrieved once to describe several instances; determining, based on thesurface description, whether a data point of the plurality of datapoints is an instance of the several instances that will havecorresponding abstract geometry that repeats the master geometry; andwhen the data point is an instance, setting the abstract geometry of theinstance to a point in the visualization about which the master geometrywill be built.
 7. The method of claim 1, reducing the primitivescomprising the abstract geometry further comprises trimming theprimitives comprising the geometry, wherein the trimming is based on thesurface description.
 8. The method of claim 1, wherein the surfacedescription includes at least one of: a type of the visualization; asize of the visualization; and a resolution for display of thevisualization.
 9. A system for providing performance optimization fordata visualization, comprising: a processor; and a memory storageincluding instructions, which when executed by the processor cause thesystem to provide: a series layout module, operable to create abstractgeometry comprising primitives to graphically represent raw dataorganized according to series in a visualization; and a layout engineoperable to receive a surface description and the raw data, furthercomprising: a data culler, operable to process the raw data to determinewhether to cull the raw data based on the surface description, wherein afirst data series of the raw data is culled when the surface descriptionindicates that a graphical representation of the first data series willbe materially affected by a graphical representation of a second dataseries of the raw data; and a geometry culler, operable to process theabstract geometry to determine whether the abstract geometry can beculled, wherein culling the abstract geometry reduces the primitivescomprising the abstract geometry without materially affecting thevisualization to thereby improve rendering efficiency.
 10. The system ofclaim 9, wherein the layout engine is operable to receive the raw dataand the surface description from a client operable to render thevisualization, and to transmit the visualization to the client.
 11. Thesystem of claim 9, wherein the abstract geometry is stored as seriesobjects within continuous blocks of memory, wherein each series objectcorresponds to one data series and is configured for near-constantretrieval.
 12. The system of claim 9, wherein the determination to cullthe first data point is based on a custom culling logic corresponding toa type of the visualization.
 13. The system of claim 9, wherein thedetermination to cull the abstract geometry is based on a geometryculling logic that indicates the abstract geometry to cull based on asize threshold for the abstract geometry, wherein the size threshold isbased on the surface description.
 14. The system of claim 9, wherein thedata culler is further operable to, based on the surface description,cull the first data series when a number of data series comprising theraw data exceeds a display area of the visualization.
 15. The system ofclaim 9, wherein the geometry culler is operable to combine collinearprimitives to reduce the primitives.
 16. The system of claim 9, whereinthe geometry culler is operable to drop negligible geometry from thevisualization to reduce the primitives.
 17. The system of claim 9,wherein the geometry culler is to operable trim the primitivescomprising the abstract geometry to reduce the primitives, wherein thetrimming is based on the surface description.
 18. A computing device forproviding performance optimization for data visualization comprising: aprocessor; and a memory storage including instructions, which whenexecuted by the processor cause the computing device to be operable to:receive data including raw data, comprised of a plurality of data pointsto be displayed via graphical representations in a visualization, and asurface description for the visualization; process the raw data based ona custom culling logic corresponding to a type of the visualization todetermine whether to cull a first data point from the plurality of datapoints, wherein the first data point is culled when the surfacedescription indicates that a graphical representation of the first datapoint will be materially affected by a graphical representation of asecond data point; generate abstract geometry comprised of primitives tographically represent unculled data points in the data visualization;process the abstract geometry culling logic to determine whether to cullabstract geometry based on a size threshold for the abstract geometrybased on the surface description, wherein culling the abstract geometryreduces the primitives comprising the abstract geometry withoutmaterially affecting the visualization to thereby improve renderingefficiency; and store the abstract geometry as a series object within acontinuous block of memory, the series object configured fornear-constant retrieval for the visualization.
 19. The computing deviceof claim 18, wherein the series object corresponds to a data series ofthe raw data, wherein the abstract geometry for each data series isgenerated, processed, and stored individually.
 20. The computing deviceof claim 18, wherein reducing the primitives includes at least one of:combining collinear primitives; dropping negligible geometry from thevisualization, such that the dropped negligible geometry is not stored;and trimming the primitives comprising the geometry, wherein thetrimming is based on the surface description.